1. Field of the Invention
This invention relates to establishing communication tunnels. It is particularly applicable to establishing secure tunnels, for example IPsec tunnels through VPN (Virtual Private Network) gateways
2. Description of the Related Art
The IPsec protocol provides basic security services that can be supplemented onto plain IP (Internet Protocol) traffic between two endpoints. Security Associations (SA) between the endpoints of the IPsec link are established either by manual or automatic keying processes. A general discussion of IPsec is available from “IPsec The New Security Standard for the Internet, Intranets and Virtual Private Network”, PHI, Naganand Doraswamy, et al.
VPNs are often used to connect intranets or to form an extranet over the Internet. VPN tunnels are normally implemented as IPsec sessions: a VPN endpoint, based on the security policy, acts on the plain IP traffic and applies confidentiality (ESP, encapsulating security payload) or integrity (AH, authentication header). The receiving security gateway performs the reverse process. Implementation of IPsec is a receiver-oriented operation, meaning that the receiving end should have all the necessary knowledge of how to decrypt the packet and what keys are to be used to decrypt and validate against the policy. All this information has to be in place beforehand at the receiving tunnel endpoint and this is either done manually or by using IKE (internet key exchange).
There are generally two ways in which an IPsec link can be implemented. These are illustrated in FIG. 1. In method A, a client terminal 1 establishes the IPsec link directly between itself and a remote terminal 2 over an intervening network 3, which is generally a public network such as the Internet. In method B, the client terminal connects to a security gateway (SG) 5 through a local network 4, and the security gateway establishes the IPsec link between itself and the remote terminal 2. The security gateway may have pre-established the IPsec link. In method B the terminal 1 needs to know the address of the security gateway 5 so that it can connect to it. The terminal 1 may establish a secure communication session with the security gateway 5, especially if the network 4 is insecure.
Method A is often known as a “road warrior” set-up. Method B is generally used for interconnecting corporate local area networks over an intervening public network such as the Internet.
In method A the client terminal 1 must support the processing to terminate the IPsec link. It may use either pre-shared secret keys or perform IKE (internet key exchange) to establish the session keys. This requires a considerable amount of processing power, and whilst it is suitable for devices such as laptop personal computers, it is generally unsuitable for devices such as mobile phones, PDAs (personal digital assistant) and other small portable devices that typically have less processing capacity, less memory and less battery storage. Such devices may have problems supporting VPN client applications; or it may not be possible for such devices to use many IPsec sessions to perform host-to-host or host-to-network VPN tunnels.
In typical applications, IPsec is used to provide remote access to a corporate network, which could be represented by or located behind remote terminal 2. To provide remote access to a corporate network, the VPN client application software is either pre-programmed into the client terminal (for method A), or the client terminal is made aware of the address of the security gateway (for method B). As indicated above, trust can be pre-established between the security gateway and the remote terminal 2 (which could be another security gateway).
Most corporate access systems provide their own VPN application to run on the client for providing remote access, using method A. A user of such system launches and connects to the nearest (or indeed any available) remote security gateway (equivalent to remote terminal 2) in order to gain access to the cooperate network. This may not possible for small hand held devices like mobile phone, PDAs and other portable equipment due to their limited processing, memory and energy storage capabilities.
There is an additional problem in using network-to-network VPNs when one of the IP endpoints is mobile. This is illustrated in FIG. 2. FIG. 2 shows a scenario where a VPN tunnel using IPsec has been established over a 3G UMTS/W-CDMA (Universal Mobile Telecommunications System/Wideband Code Division Multiple Access) network. A mobile node (MN) 10 is currently corresponding with a correspondent node (CN) 11. The MN is attached to an autonomous system (AS) AS1. The AS1 may be a wireless local area network (LAN) or an extranet or another network. The CN is part of another autonomous system, AS6, and further autonomous systems AS2 are also provided. AS1, AS2 and AS6 are here acting as sub autonomous systems and with AS3 form a transit network. There is a VPN tunnel 12 established between security gateway SG-1 in AS1 and security gateway SG-3 in AS6. That tunnel may be either pre-established or created specific for a certain session between the MN and the CN. Now, if the MN switches from AS-1 to AS-2, for example because MN physically moves from the coverage area of AS1 to the coverage area of AS2, the previous security associations may not be valid, and new security associations may have to be re-established from SG-2 of AS2 to SG-3 of AS6. This requires additional signalling, and may involve re-establishing the whole session between the MN and the CN. Alternatively, AS1 could tunnel all the relevant packets all the way to the MN, but this is likely to cause additional overhead in processing the IP packets at the MN; and would involve a route of AS2-AS1-AS6, which is clearly non-optimal and wastes both bandwidth and processing power of the MN and the security gateway.
Another problem that can arise for mobile nodes is that when a mobile node is turned on it does not know where it is, and so it does not know the address of the nearest security gateway.
Tunnel endpoint discovery, as identified above, partially addresses these problems as it proposes that there is a pre-established trust relationship between the two end-point security gateways or that the security gateway nearer to the remote node somehow knows the pre-established security policy and can perform IKE to establish the security association. The proposal cited above does not indicate how security policies with respect to the remote node can be added to the security gateway. The proposal might work for manually configured security gateways, but it would not scale well for IP mobility solutions. In addition, if both ESP (encapsulating security payload) and AH (authentication header) were applied at the same tunnel endpoint, then confidentially and integrity are satisfied only towards the other endpoint and there is no way to specify or detect multilateral and multilevel SAs.
There is therefore a need for an improved way of establishing communication tunnels, especially to address the problems discussed above in relation to mobile terminals.